Web2.0時代の必要技術　～　SOA 再入門

システム開発にとってのSOAの意義とリスク

さて、こうした特徴をもつSOAは、システム開発の点で、どんな意義を持つのだろうか。

「部品化・共通化の促進」というのは、システム開発の効率化を図るうえで何度も検討されてきた大切な要素である。しかし、現実には、それほどうまく部品化や共通化を図れるわけではなかった。また逆に、共通化や部品化を徹底したために、特定の機能の仕様が変更になったときに、共通部品によるバグが誘発されるということさえ起こりかねなかった（もっとも最近では、たとえば.NETの開発環境にすでに部品が用意されるなどして、開発環境での部品の提供が進んでいて便利である）。

共有化・共通化という観点からすれば、SOAのサービスは、事実上、独立性のある汎用的な「部品」を提供していることになる。たとえば、ログインの認証はさまざまなシステムで共通して行う必要があるかもしれない。その場合、各システムにログイン認証のプログラムを組み込むことが多かったかもしれないが、そうすると、ログイン認証プログラムに変更を加えた場合、関係するすべてのシステムを変更しなければならなかった。しかし、ログイン認証をSOAのサービスとして「部品化」するなら、ログイン認証サービスのインターフェイスさえ変わらなければ、プログラムの改修はその独立したサービスの中でのみ行える。

さらに、ここで開発されたログイン認証サービスは、その会社の他のシステムでも共通部品としてそのまま利用できる。ファイルサーバーにプログラムのソースとして眠っている部品ではなく、現実に稼動しているサービスとしての部品の持つ力は大きいといえるだろう。SOAには、「部品化・共通化」を促進する可能性がある。（図7）

　さて、システム開発の工程に目を向けてみよう。SOAにしたがってサービスの形で、機能分割するなら、システム開発分野での「共同作業」が行いやすくなるといえる。サービスごとに担当チームを決めるなら、Webサービスとしてのテストを始めるまで、各機能を独立して開発できるからである。これはオフショア開発の範囲や分担を決める上でも、役に立つだろう。

そして、サービスの独立性を考えると、結合テストや統合テストの環境についても、条件さえ整えば「非集中化」が可能である。あるサービスを中国で開発してテスト運用し、別のサービスをベトナムで開発してテスト運用し、そして国際的な「非集中化」の環境で結合テストが終わったなら、本番環境での最終的な統合テストを行うことも可能になる。その意味においても、国際的な「共同作業」を促進するといえるかもしれない。

SOAが影響を与えるのは、実装やテストフェーズだけではない。要件定義や設計の段階も関係している。SOAに従うなら、「ビジネスワークフローの改善」を検討できるというメリットがあるからである。

SOAにおいて、システムはサービスを順次呼び出しながら処理を進める。別の言い方をすれば、使用するサービスの内容を検討し、それを使う「ワークフロー」を定義すれば、システムはおおよそ決まるのである。このワークフローの分析と検討をサポートするために、SOAでは、BPMN（Business Process Modeling Notation）という表記法を使うことができる。BPMNは、業務プロセスをサービスの呼び出しという形で分析するためのツールとなる。（図8）

また、SOAには、BPMNに基づいたワークフローをXMLで記述するためのBPEL（Business Process Execution Language）という言語も用意されている。さらにBPELの関連プロダクトには、ワークフローを記述したXMLデータ（BPELのデータ）を読み込んで、順次サービスを呼び出して実行していくBPELエンジンもある。BPELエンジンは、ビジネスプロセスのワークフローエンジンである。（図9）

したがって、極論すれば、SOAに基づくシステムは、利用するサービスさえ存在していれば、BPELの記述を用意してBPELエンジンを実行すればよいのである。こうしたSOAは、システム開発の新たなパラダイムを作り出す可能性も秘めているのかもしれない。この点については、本特集の第二部で述べることにする。

夢のようなSOAと思えるかもしれないが、当然のことながら、リスクも多々ある。そのいくつかを取り上げてみよう。

まず、SOAでは、サービスの定義が重要だということである。特にサービスの大きさ（粒度）がかぎである。粒度の決定で失敗すると、システムは動いたとしても、開発の生産性や運用時のパフォーマンスの点で、思うような成果を上げられないかもしれない。

また、個々のサービスをどのサーバーで運用するかにも注意が必要である。必ずしもサービスごとにサーバーを用意する必要はない。しかし、すべてを一つのサーバーで運用するなら、非集中化のメリットを受けられなくなる可能性もある。

さらに、サービス運用の相互作用も考慮する必要がある。あるサービスがダウンしたときに、その影響がどの範囲に波及するか、SOAを採用したことでシステムダウンのリスクがかえって大きくならないか、十分に検討する必要があるだろう。

SOAをサポートするツールや開発環境はまだまだ高額であり、事実上、大規模システムでしか使えないような状況である。SOAが普及するには、オープンソース・ソフトウェアも含めて、開発環境・運用支援環境の充実と価格の低下が望まれるところである。

「フラット化」とSOA

　さて、ここまで主として、SOAの技術的な側面について述べてきた。SOAは将来性のある技術である。システム開発において伝統的なモジュールやコンポーネントとは概念の異なるサービス中心の考え方、サービスの疎結合と集約、システムの非集中化、ビジネスプロセスエンジンなど、新たなコンセプトが入っている。

これはサービスという切り口で、またHTTPやSOAPというプロトコルによって、ソフトウェア機能をフラットにしたといえるかもしれない。また、サービスというコンセプトにより、ソフトウェア機能だけでなく、それに付随する実務（発送、決済など）のアウトソーシングの可能性を増やしている。

SOAはフリードマンが述べた「世界のフラット化」が進む時代に、またフラット化の重要な要因である「インターネット」や「XML、SOAP」の技術の上に登場したソフトウェア開発のコンセプトである。大きな時代の流れの中で、SOAの考え方がシステム開発の付加価値と生産性を高めるものとなるように期待している。